IoTデバイスのソフトウェアアップデートと「AWS IoT Jobs」

概要

IoTデバイスをリリースした後もバグフィックスや機能追加等を目的にソフトウェアアップデートを実施することがあります。 ソフトウェアアップデートを実現するために考慮するといい点（個人の感想です）と、ソフトウェアアップデートを実施する際にとても便利なAWS IoT Jobsについて紹介します。

目次

• 1.考慮するといい点
• 2.「AWS IoT Jobs」はいいぞ
• 3.まとめ
• 4.参照

1.考慮するといい点

IoTデバイスのユースケースによりますが、以下5点は考慮しておくといいと思います。

関係者への周知

ソフトウェアアップデートの影響を受ける可能性がある関係者を整理し、関係者に事前に「ソフトウェアアップデートが実施されることがあります、その場合はこういう影響がありますのでこうしてください」等の内容をアナウンスしましょう。（IoTデバイスのエンドユーザーに限らず、開発担当者、保管庫の責任者、運搬担当者、様々な関係者がいるはずです）

また、「ソフトウェアアップデート実行時関係者に何らかのアクションをして欲しい」場合は、デバイスが周囲の人に「ソフトウェアアップデートをすること」を通知できる（ex.画面に表示、音声アナウンス、ライト）と便利です。

対応範囲の明確化

ソフトウェアップデートの仕組みの対応範囲を明確に定義し、必要な場合は関係者と合意しましょう。

ソフトウェアアップデートの仕組みも、例えば「AWS IoT Jobs」等の仕組みを使えば実装次第でなんでも（ex.AWSからシェルコマンドをデバイスに送って実行させる)できてしまいますが、自由度を高めるとトラブルが発生する可能性も高まるので注意が必要です。

デバイスのバージョン確認を簡単にできるか

サーバー側IFの更新や、セキュリティ向上のためのアップデート等、必ず全デバイスにアップデートを適用しないといけない場合があります。その場合に「アップデートできていないデバイスがないか、あるならどれか」を簡単に確認できる仕組みが必要です。

具体的には、「ソフトウェアアップデートの履歴データ」、「バージョン等で簡単にクエリをかけられる仕組み」等があると良いです。

トリガーは何か

ソフトウェアアップデートを実行するトリガーとして、まずは「クラウドからデバイスに対してアップデートを促すトリガー」が欲しいところです。サーバー側で後方互換性のない機能変更発生時やバグフィックス等、クラウドから強制的に全デバイスに対してソフトウェアアップデートを実施したいケースは往々にして発生するためです。

しかしながら、アップデートが失敗した場合にその都度クラウドの担当者がデバイスの担当者とスケジュールを再調整してアップデートを再実施、となってしまう場合はいささか不便です。その場合はデバイスの担当者からアップデートを実行できるトリガーを用意することも有用です。 （ex.デバイスにボタンorレバーを設置、特定のQRコードを読みこませる、関係者が利用できるシステムやアプリの用意）

失敗時に把握できる仕組み

ソフトウェアアップデートが失敗した場合に運用担当者に通知する仕組みがあると良いです。もしこの仕組みがない場合は「デバイスのバージョン確認を簡単にできる」仕組みがないと運用時に辛いかもしれません。

2.「AWS IoT Jobs」はいいぞ

ここまではソフトウェアアップデートをするにあたって考慮するといいと思う点を書いてきました。続いて、ソフトウェアアップデートを実現するための強い味方である「AWS IoT Jobs」について簡単に紹介します。 （AWS IoT Jobsを利用するにあたって、デバイスはIoT CoreでThingとして管理されていることが前提です）

注意点として、「AWS IoT Jobs」は「ソフトウェアアップデート以外」にも利用できます。 「AWS IoT Jobs」はAWSとデバイスがMQTTメッセージを介していろいろやり取りする仕組みなので、デバイス側の実装次第で自由度高く様々なことが実現できます。 今回はその上で「AWS IoT Jobsを使ってソフトウェアアップデートをする」という前提で「AWS IoT Jobs」について紹介します。

履歴データの登録

以下のようにJobの履歴を保存してくれます。 Jobの実行結果の概要がぱっと見でわかるのは嬉しいですね。

以下のように「Jobのステータス（ex.失敗、成功）」から検索できたり、ThingNameから検索できたりしてとても便利です。

このデータは730日間保存してくれるので、殆どのユースケースでは十分かと思います。

参照: AWS IoT ジョブ

ロールアウト設定

最初は少しのデバイスにJobを適用し、ある程度成功してきたらより多くのデバイスにJobを適用する、といったようなデプロイ速度の調整が簡単にできます。例えば、最初は1分あたり4デバイスにのみJobを適用しつつ、10台成功するごとに1分ごとにJobを適用するデバイス数を2倍にするといったような制御ができます。また、デプロイ速度の最大値も設定できるのでバックエンド側のスロットリング問題を回避できます。

参照: ジョブの 設定

ただし、2022年3月時点では、JobのTargetを動的グループにしている場合はこの機能が使えなかったので、ターゲットを静的グループにしたりThingのリストにする等の対策が必要です。

中止設定

「指定した閾値以上のデバイスにJobが適用された状態で、指定した割合以上のデバイスでJobが失敗したらJobを中止する」といったような制御ができます。例えば、「10台以上のデバイスにJobが適用された状態で、20%以上のデバイスでJobが失敗したらJobを中止する」といったような形です。この設定と先ほど説明した「ロールアウト設定」を合わせることで、安全にJobを実行することができます。（問題があるJobを実行した場合に、影響のあるデバイス数を少なくできる）

参照: ジョブの 設定

Job失敗時のリトライ

デバイス側の状況によっては挙動がファジーなこともありえます。その場合は同一内容でもリトライができると嬉しいケースがあります。 しかし、リトライしない方がいいケースもあったり、再試行するたびにAWSコストが嵩むこともあるので、再試行の設定はケースbyケースですね。

その他

2022年3月時点では、Jobの実行日時を細かく制御することはできません。 実行日時を細かく制御したい場合はJobの作成タイミングを制御するしかないので、EventBridgeRule等でRuleを作って指定した日時にJobを作る、といった対応がいいかと思います。

3.まとめ

結構いろいろ考えることはありますが、最終的には「IoTデバイスが何台あって、誰がどこでどのように使っているのか」等の要素によって最適な実現方法は大きく異なります。その上で、「AWS IoT Jobs」は様々な便利機能を提供してくれるのでおすすめです。

4.参照

• AWS IoT Jobs
• AWS IoT Device Management エンドポイントとクォータ
• ジョブの 設定